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RELEASE OF FUNDS BASED ON CRITERIA 

5 RELATED APPLICATIONS 

This application claims the priority benefit of U.S. Provisional Application 
No. 1 1/238,359, filed September 29, 2005, the content of which is incorporated 
herein by reference. 

10 FIELD 

The disclosed subject matter relates generally to the technical field of data 
processing and, in one example embodiment, to a method and system of releasing 
funds associated with a network-based commerce transaction based on criteria. 



15 BACKGROUND 

For users of a network-based commerce transaction, a reliable and 
convenient payment mechanism is particularly important for enhancing user trust in 
the transaction facility. A typical network-based transaction facility, however, does 
not ensure the expedient and secure completion of payment transactions. For 

20 network-based commerce transactions, often the seller is directly paid by the buyer. 
This is risky for buyers because the buyers may receive a defective product, a 
misrepresented product, or not receive the product at all. Further, disreputable 
sellers may not be motivated to resolve any dispute because they have already 
received funds. 

25 For some markets, buyers and sellers may instead agree to use an escrow 

account for the buyer to deposit funds. The buyer may instruct the escrow holder to 
release the funds to the seller upon satisfactory receipt of the item. However, the 
seller may wait a prohibitively long time to receive funds, that is, until the buyer 
receives the item and approves of funds release. 

30 Accordingly, current payment transactions may delay payments to sellers 

and delivery of purchased goods to buyers. 
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SUMMARY 

According to one embodiment, a system and a method to transfer payment to 
a seller of a network-based commerce transaction are described herein. The method 
5 includes generating a risk model based on seller-specific criteria, and releasing 
funds from a holding account to the seller based on the risk model. 

Other features will be apparent from the accompanying drawings and from 
the detailed description that follows. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Embodiments of the present invention are illustrated by way of example and 
not limitation in the Figures of the accompanying drawings, in which like references 
indicate similar elements and in which: 

Figure 1 illustrates a network diagram depicting a system, according to an 
15 example embodiment of the present invention, having a client-server architecture. 

Figure 2 illustrates a block diagram showing an application server in an 
example embodiment of the present invention. 

Figure 3 illustrates a high-level entity-relationship diagram, illustrating 
various tables that may be maintained within one or more databases, according to an 
20 . example embodiment. 

Figure 4 illustrates an interaction/flow chart according to an example 
embodiment. - 

Figure 5 illustrates a block diagram showing an application server in an 
example embodiment of the present invention. 
25 Figure 6 illustrates a diagrammatic representation of a machine in the form 

of a computer system within which a set of instructions, for causing the machine to 
perform any one or more of the methodologies discussed herein, may be executed, 
according to an example embodiment. 
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DETAILED DESCRIPTION 
Embodiments describe a method and a system to transfer payment to a seller 
of a network-based commerce transaction. The method includes generating a risk 
model based on seller-specific criteria, and releasing funds from a holding account 
5 to the seller based on the risk model. 

In the following description, for purposes of explanation, numerous specific 
details are set forth in order to provide a thorough understanding of embodiments of 
the present invention. It will be evident, however, to one skilled in the art that 
embodiments of the present invention may be practiced without these specific 
10 details. 

Platform Architecture 

Figure 1 illustrates a network diagram depicting a system 100 having a 
client-server architecture, according to an example embodiment of the present 

15 invention. The system 100 includes a client machine 102, such as a buyer's 

machine, a client machine 104, such as a seller's machine, and a network-based 
system 1 12, such as a network-based commerce system, coupled by a network 114. 
A system, in the example form of the network-based system 112, provides server- 
side functionality, via the network 1 14 to one or more clients. 

20 The network 1 14 may, for example, be the Internet, a public or private 

telephone network (wireline or wireless), a private wireless network using 
technologies such as Bluetooth or IEEE 802.1 lx or other networks. The network 
114 may include a mobile telephone network, a wireless wide area network 
(WWAN), a wireline telephone network, a wireless local area network (wireless 

25 LAN or WLAN), a wireless Metropolitan Area Network (MAN), and/or a wireless 
personal area network (PAN) (e.g., a Bluetooth® network). Other network-based 
technologies that may be used to connect include PON, VSAT satellite, Micro- 
impulse Radar, Radio Frequency identification (RFID), Ultra Wide Band, and/or 
Infrared. The network-based device may connect to the web using mobile internet 

30 exchange, e.g. Wireless Application Protocol (WAP) and/or Hypertext Transport 
Protocol (HTTP). 
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The client machines 102, 104 may include any network-based device, such 
as a mobile device, a palmtop computer, a laptop computer, a desktop computer, a 
personal digital assistant, a cellular telephone, a communications device, a wireless 
telephone, a land-line telephone, a control system, a camera, a scanner, a television, 
5 television cable, a telephone with a web browser, a facsimile machine, a printer, a 
pager, and/or a personal trusted device. The device may be browser-enabled. 

Figure 1 further illustrates, for example, a client 116 (e.g., a web client such 
as a web browser, Internet Explorer ® browser developed by Microsoft ®, and/or a 
programmatic client) that may execute on the client machine 102, 104. 
10 Turning specifically to the network-based system 1 12, a server 124, such as 

a Application Program Interface (API) server, a Short Messaging Service (SMS) 
Gateway Server, a web server, or an Interactive Voice Response (IVR) server may 
be coupled to, and may provide programmatic, SMS, web, and IVR interfaces, 
respectively, to one or more application servers 128. The machines 102, 104 may 
15 use one or more of these interfaces to access the application server(s) 128. 

Further, while the system 100 shown in Figure 1 employs a client-server 
architecture, embodiments are of course not limited to such an architecture, and 
could equally well find applications in a distributed, or peer-to-peer, architecture 
system. 

20 The application server(s) 128 may host one or more payment application(s) 

132. The application server(s) 128 are, in turn, shown to be coupled to one or more 
database servers 134 that facilitate access to one or more databases 136. 

The payment application(s) 132 may provide a number of payment services 
and functions to users, such as client users, for example: vendors or sellers and 

25 buyers. The payment application(s) 132 may allow users to accumulate value (e.g., 
in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as 
"points") in accounts, and then later to redeem the accumulated value for an offer 
(e.g., goods, services, promotions, or donation opportunities). The payment 
applications may also extend credit to user, and/or may also have access to other 

30 funding sources to complete transactions - e.g. a credit card, a bank account, and/or 
a credit line. A financial service provider may operate as a money transmitter or a 
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bank, for instance, and may operate using the payment application(s) 132. 

The payment application(s) 132 may have an infrastructure to pay a plurality 
of vendors for a plurality of transactions each day. The payment application(s) 132 
may also be implemented as a standalone software program, which does not 
5 necessarily have networking capabilities. 

The payment application(s) 132 may have access to the database 136 having, 
for example, the personal user account information through, for example, the 
database server(s) 134. The user account information may include payment 
information associated with the seller and a shipping address of the buyer, for 

10 example. The programmatic or web client 116 may operate a program supported by 
the one or more database server(s) 34. The database server(s) 134 may support one 
or more account information links on a user interface of the machine 102 or 104, for 
example, using the client 116. By accessing the database server(s) 134, the client 
user may add, amend or delete account information of the client user, among other 

1 5 information. One of the default payment methods may include direct transfers from 
system account balances, internal credit, a gift certificate, a bank account, a debit 
card, buyer credit, and/or a credit card into a holding account 150 of the payment 
application(s) 132, as shown in Figure 2 or into an escrow account 450 of the 
payment application(s) 452, as shown in Figure 5. 

20 

Application Server(s) 

Figure 2 illustrates a block diagram showing application server(s) that are 
part of the network-based system 1 12, in an example embodiment of the present 
invention. In this embodiment, the payment application(s) 132 may be hosted by 
25 the application server(s) 128 of the network-based system 112. 

The payment application(s) 132 may include a payment transfer module 142, 
fraud prevention application(s) 144, funds release application(s) 146 (such as a 
funds release module), dispute resolution application(s) 148, and/or holding 
account(s) 150. 

30 The payment transfer module 142 may be responsible for executing payment 

transactions in transferring a payment from the buyer (e.g., buyer account) to the 
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seller (e.g., seller account) via the payment application(s) and/or the financial 
service provider. The payment may be automatically transferred directly or may 
transfer through one of the holding accounts 150 between parties of the commerce 
transaction. 

5 The payment application(s) 132 receives information from the transaction 

facility, stores some or all of this information for historical purposes in the database 
136, and determines what information to pass to the fraud prevention application(s) 
144 and the funds release application(s) 146. The fraud prevention application(s) 
144 and the funds release application(s) 146 may each utilize this information to 

10 determine a risk level involved in the payment transaction. In one embodiment, 
input from one or more third party risk analysis providers (e.g., credit rating 
agencies) may be used to evaluate the risk level of the payment transaction. The 
results of the evaluation are passed back to the funds release application(s) 146 
and/or the fraud prevention application(s) 144, which continue processing the 

15 payment transaction based on the evaluation results. 

The fraud prevention application(s) 144 may implement various fraud 
detection and prevention mechanisms to reduce the occurrence of fraud within the 
system 112. The fraud prevention application(s) may prevent fraud with respect to 
the third party and/or the client user in relation to any part of the request, payment, 

20 information flows and/or request fulfillment. Fraud may occur with respect to 
unauthorized use of financial instruments, non-delivery of goods, and abuse of 
personal information. The fraud prevention application(s) 144 may also work 
closely with (and/or similarly to) the funds release application(s) 146, and vice 
versa. 

25 The funds release application(s) 146 may include a risk model 147, The risk 

model 147 may be generated using data from the database(s) 136, which may 
include data tables 200 of Figure 3. The data tables 200 of Figure 3 may include a 
transaction-specific table 210, a buyer-specific table 220, and/or the seller-specific 
table 230 to track data regarding the transaction, data regarding the buyer, and data 

30 regarding the seller, respectively. 

The risk model 147 may evaluate the accumulated data at various stages of 
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the payment transaction to assess potential involved risks. The involved risks may 
concern, for example, a likelihood that a seller may be fraudulent (e.g., a seller lists 
goods for sale online with no intent or ability to deliver the purchased goods), or a 
seller's ability to fulfill purchase orders promptly. Based on the risk evaluation, the 
5 payment application(s) 132 may restrict a payment transaction between a buyer and 
a seller. In one embodiment, the risk evaluation is performed in real time and may 
enable an uninterrupted processing of the payment transaction. 

Based on the information received from various sources, the risk model 147 
may determine the risk level of the payment transaction using a scoring algorithm. 

10 It should be noted that any scoring algorithm known in the art may be used by the 
risk model 147 without loss of generality. The risk model 147 may produce a 
consolidated risk response and passes it to the payment transfer module 142. The 
risk response may include, for example, information indicating that service should 
be denied to a participant due to high likelihood of fraud, information on a 

1 5 recommended service fee for processing the payment transaction, information on 
recommended restrictions on payment instruments to be used by either the buyer or 
the seller, and/or information on recommended restrictions on disbursing funds to 
the seller. 

The payment transfer module 142 receives the risk response and acts 
20 according to the information provided. That is, the payment transfer module 142 
may reject the payment transaction (or deny service to either the buyer or the seller 
entirely), process the payment transaction without any changes, or restrict (timing, 
and/or amount) the payment or manner in which the payment transaction is 
conducted. For example, the payment transfer module 142 may limit payment 
25 instruments offered for use in the payment transaction, may assign or modify a fee 
for processing the payment transaction, or may restrict the time, amount, or the 
manner in which funds are disbursed to the seller. 

The amount of funds released from the holding account 150 (or the escrow 
account 450) may vary according to the risk model assessment. The funds may be 
30 released from the holding account 150 (or the escrow account 450) to the seller 

based on the assessment by the risk model 147. For example, 95% of the funds may 
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be released within or at 30 days. In another example, a certain percentage of a 
seller's average monthly transactions may be released immediately. 

In addition, or alternatively, the timing for release of the funds from the 
holding account 150 (or the escrow account 450) may vary according to the risk 
5 model assessment. For example, the funds may be released at a time, e.g. 0 days, 15 
days, or 30 days, after the funds are received into the account 150 (or 450). The 
funds release may be partial or full at the specified time, depending upon the 
circumstances or specifications of the funds release application(s). The release of 
the funds to the seller may thus be completed in a plurality of stages over a period of 
1 0 time, wherein the plurality of stages and the period of time is determined by the risk 
model assessment. For example, half of the funds may be released at 0 days, 25% 
may be released at 15 days, and the remaining percentage may be released at 30 
days. 

The funds release application(s) 146 may continuously (or on a periodic 
15 basis) trace transactions, e.g., a seller's transactions on a daily basis, and therefore 
the variable time or variable amount release may dynamically change. For instance, 
if the seller has a substantially large increase in velocity of trade and thus has a large 
amount of funds held in a holding account, funds may be released much more 
quickly. 

20 In an additional embodiment, the seller may have given the payment 

application(s) 132 assurances, such as a security proxy or collateral, in exchange for 
minimizing the amount of funds held and/or for minimizing the time the funds are 
held. For example, if the seller has given the payment application(s) a valid social 
security number, financial services provider account information (e.g., bank account 

25 number, credit card account number, PayPal account access), a large amount of cash 
or some other proxy of security, the amount of time and amount of funds held may 
be minimized for that seller. The security proxy may also be considered a factor in 
the risk model 147 of the funds release application(s). 

In one embodiment, the payment application(s) 132 may charge fees that 

30 vary according to the risk model assessment for each seller. For example, the fees 
may be reduced for more "trusted" sellers. In an additional embodiment, the seller 
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may be considered a top tier seller in the network-based commerce system (e.g. an 
eBay® PowerSeller™) and/or in the payment application(s). This top tier status 
may result in paying lower fees of the payment application(s), and/or in having 
quicker access to funds in holding accounts. This top tier status may be dynamic 
5 and may also depend on other factors, such as those factors considered by the risk 
model 147. 

From a system point of view, the risk model 147 may aid in controlling risk 
exposure associated with the payment application(s) 132. For example, the risk 
model 147 evaluates the risk that the buyer will not receive the item paid for, or will 

10 receive an unacceptable item, and that the seller will have an unsatisfactory 

response. In this instance, if the seller is not able to reimburse the buyer (or the 
payment application(s)), or refuses to make the reimbursement, the payment 
application(s) may then reimburse the buyer, thus affecting the risk exposure 
associated with the payment application(s). In this embodiment, the buyer is 

15 assured of "safe payments." In alternate embodiments, the buyer may absorb the 
risk. 

The dispute resolution application(s) 148 may provide mechanisms whereby 
disputes arising between transacting parties may be resolved. For example, the 
dispute resolution applications 148 may provide guided procedures whereby the 

2D parties are guided through a number of steps in an attempt to settle a dispute. In the 
event that the dispute cannot be settled via the guided procedures, the dispute may 
be escalated to a mediator or arbitrator. In an event where the seller and buyer do 
not come to an agreement and the buyer never received the item, or received a 
defective item, the payment application(s) may reimburse the buyer. If the funds in 

25 the holding account 150 have not yet been released to the seller, the funds in the 
account may be given back to the buyer. 

The holding account 150 may be a transaction-specific holding account, 
and/or the holding account 150 maybe a general seller-specific holding account 
associated with pending seller transactions, with or without sub-accounts for 

30 specific transactions. In any instance, the seller may associate collateral with the 
holding account directly or through another seller account associated with the 
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payment application(s). 
Data Structures 

Figure 3 illustrates a high-level entity-relationship diagram, illustrating 
5 various tables 200 that may be maintained within the database(s) 136 according to 
an example embodiment. The tables 200 may be utilized by and support the 
application(s) of the application server(s). The database(s) 136 may, in one 
embodiment, be implemented as a relational database, and includes a number of 
tables having entries, or records, that are linked by indices and keys. In an 
1 0 alternative embodiment, the database(s) 136 may be implemented as collection of 
objects in an object-oriented database. 

The tables 200 may include a transaction-specific table 210, a buyer- specific 
table 220, and a seller-specific table 230. the transaction-specific table 210, the 
buyer-specific table 220, and the seller-specific table 230 may each include a record 
15 for each transaction, each buyer, and each seller, respectively, of the network-based 
system 1 12. A user may, it will be appreciated, operate as a seller, a buyer, or both, 
within the network-based system 1 12. 

The transaction-specific table 210 may include a record for the specific 
transaction (e.g., a purchase transaction) under consideration in the risk model 147. 
20 The transaction-specific table 2 1 0 may include information such as the buyer, the 
seller, the description of the item, the price paid, the date, the quantity sold, the item 
identification number, the item category, and other transaction-related information. 

The buyer-specific table 220 may include the buyer identification number, 
the buyer site identification, such as the IP address of the associated machine, the 
buyer country, and other buyer-related information. 

The seller-specific table 230 may include the seller identification number, 
the seller site identification, such as the IP address of the associated machine, the 
seller country, the seller tier category, a tenure time associated with the network- 
based commerce system, security proxy, such as collateral associated with the 
holding account from the seller, a social security number of the seller, or a financial 
services provider account number of the seller, and other seller-related information, 
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such as consistent volume sales, a high percentage total positive feedback for a 
minimum number of ratings, network-based marketplace policy compliance, a 
payment application account in good financial standing, and averaging a minimum 
monetary amount in sales per month for a minimum number of consecutive months. 
5 The seller-specific table 230 may further be associated with a transaction 

history table 232 of the seller, a feedback table 236 of the seller, and a velocity of 
trade table 234 of the seller. The transaction history table 232 may include an item 
identification number, a sale amount, a date, a buyer identification number, a 
description, a quantity sold, and an item category for each transaction with which 
10 the seller is associated. The feedback table 236 may include peer review and a 
complaint rate related to the seller for various network-based transactions. The 
velocity of trade table 234 may include a volume of trade per month for items that 
the seller sells on the network-based commerce system. 

1 5 Interaction/Flowchart 

Figure 4 illustrates an interaction/flow chart of a method 300, according to 
an example embodiment of the present invention. The interaction chart is divided 
into several categories, including the seller, the funds release application(s) 146, and 
the buyer, representing actions taken by or at that user or application. 

At block 310, seller places an item in commerce. The item may be placed in 
the network-based system 1 12 for sale. The item may be offered for sale in an 
auction sale, or may be offered for sale at a fixed-price. 

At block 320, the buyer indicates intent to purchase the item placed in 
commerce. The item may have been won in the auction or the buyer may have 
indicated, in another way, intent to purchase the item offered at the fixed-price. The 
buyer may then transfer funds into the holding account 150. 

At block 330, the funds release application(s) determines the amount of 
funds to hold back from the seller in the holding account, and/or determines for how 
long to hold back the funds, based on the risk model assessment using the criteria 
gathered from the database. 

At block 340, funds from the holding (or escrow) account are released to the 
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seller by the payment transfer module 142 per the assessment from the risk model 
147 of the funds release application(s) 146. 

At block 350, the item is sent to the buyer at the direction of the seller. The 
item may be sent after or before funds are released to the seller or even during funds 
5 release. 

At block 360, the buyer receives the item sent at block 350. 

At block 370, the buyer approves the item received at block 360 and the 
transaction is completed. It will be appreciated that the funds may or may not have 
been released to the seller before buyer approval. However, upon buyer approval, 
10 the funds may be released, if not done so already. 

At block 380, alternative to block 370, the buyer initiates the dispute 
resolution process, for example, when the buyer does not approve of the item (e.g., 
the item is not as described, or is defective), or if the buyer does not receive the 
item. The dispute resolution process may start with a simple communication to the 
15 seller of the issue. The buyer and seller may use the dispute resolution 
application(s) 148 to resolve the issue. 

Another Embodiment of an Application Server(s) 

Figure 5 illustrates a block diagram showing application server(s) 400 in an 

20 example embodiment of the present invention. The application server(s) 400 may 
replace the application server(s) 128 of the network-based system 1 12 of Figure 1 in 
certain environments. In this embodiment, the application server(s) 400 may host 
one or more marketplace application(s) 410, and one or more payment 
application(s) 452 (similar to payment application(s) 132, except application(s) 452 

25 has an escrow account 450 rather than a holding account 150), 

The buyer may "shop" or search, using one or more marketplace 
application(s) 410, for an offer associated with the seller. The marketplace 
application(s) 410 may provide a number of marketplace functions and services to 
buyers, sellers, and/or to third parties, who access the system 1 12. The marketplace 

30 applications 410 may provide a number of offering mechanisms and price-setting 
mechanisms; whereby a seller may list goods or services for sale, a promotion or a 
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donation opportunity, a seller may promote their offers, a buyer can express interest 
in or indicate a desire to purchase such goods or services or to donate, and a price - 
can be set for a transaction pertaining to the goods or services, or donation 
opportunity. 

5 The marketplace applications 410 may include one or more store 

applications 414. In an embodiment, the store applications 414 allow sellers to 
group their offers within a virtual store, which may be otherwise personalized by 
and for the sellers. Such a store may also offer promotions, incentives and features 
that are specific to and personalized by the respective seller. 

1 0 Navigation of the network-based system 1 1 2, including through the store 

application(s) 414, may be facilitated by one or more navigation applications 416. 
The one or more navigation application(s) may include a search module 418. The 
navigation application(s) may enable key word searches of 
products/services/promotions/donations published via the system 1 12. A browse 

15 application allows users to browse various category (e.g. music, books, offer price, 
shipping price), catalogue, or inventory data structures according to which 
products/services/promotions/donation may be classified within the system 112. 
Various other navigation applications may be provided to supplement the search and 
browsing applications, 

20 The marketplace applications 4 1 0 may include one or more fixed-price 

application(s) 420. The fixed-price applications 420 support fixed-price offer 
formats and buyout-type offers. The fixed-price offer format may include, for 
example, the traditional classified advertisement-type offer, a catalogue offer, a 
television advertisement offer, a magazine offer, a website offer, an SMS offer, a 

25 data services offer, a billboard offer, a banner ad offer, or any other type of virtual 
or physical marketplace medium. The fixed-price offer in any of these listed 
formats may be considered the point of sale. In an additional embodiment, the 
client user may use the navigation application(s) to find the fixed-price offer. 

In an embodiment, buyout-type offers (e.g., including the Buy-It-Now (BIN) 

30 technology developed by eBay Inc., of San Jose, California) may be offered in 

conjunction with an auction-format offer. The buyout-type offer may allow a buyer 



13 



WO 2007/04 J 103 



PCT/US2006/037496 



to purchase goods or services or make a donation, which are also being offered for 
sale via an auction, for a fixed-price that may be higher than the starting price of the 
auction. The buyout-type offer in any of these listed formats may be published in 
any virtual or physical marketplace medium and may be considered the point of 
5 sale. The offer may be accepted by the client user by indicating consent to the offer. 
In an additional embodiment, the client user may use the navigation application(s) 
to find the buyout-type offer. 

The marketplace applications 410 may include one or more auction 
applications 422 that support various auction-format offer and price setting 

10 mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions, 
etc.). The various auction applications 422 may also provide a number of features 
in support of such auction-format offers, such as a reserve price feature whereby a 
seller may specify a reserve price in connection with an offer and a proxy-bidding 
feature, whereby a bidder may invoke automated proxy bidding. The auction- 

1 5 format offer in any format may be published in any virtual or physical marketplace 
medium and may be considered the point of sale. In an additional embodiment, the 
client user may use the navigation application(s) to find the auction-format offer. 

The marketplace applications 410 may include one or more personalization 
applications 424. The personalization application(s) 424 may allow third parties to 

20 personalize various aspects of their interactions with the system 1 12, For example 
the third party may, utilizing an appropriate personalization application 424, create a 
personalized reference page at which information regarding transactions to which 
the third party is (or has been) a party may be viewed. Further, the personalization 
application(s) 424 may enable a third party to personalize products and other aspects 

25 of their interactions with the system 112 and other parties, or to provide other 
information, such as relevant business information about themselves. 
The marketplace applications 410 may include one or more internationalization 
applications 426. In one embodiment, the network-based system 1 12 may support a 
number of marketplaces that are customized, for example, for specific geographic 

30 regions. A version of the system 1 12 may be customized for the United Kingdom, 
whereas another version of the system 1 12 may be customized for the United States. 
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Each of these versions may operate as an independent marketplace, or may be 
customized (or internationalized) presentations of a common underlying 
marketplace. 

The marketplace applications 410 may include one or more reputation 

5 applications 428. The reputation applications 428 allow parties that transact 

utilizing the network-based system 1 12 to establish, build, and maintain reputations, 
which may be made available and published to potential trading partners. Consider 
that where, for example, the network-based system 1 12 supports person-to-person 
trading, users may have no history or other reference information whereby the 

10 trustworthiness and credibility of potential trading partners may be assessed. The 
reputation applications 428 allow a user, for example through feedback provided by 
other transaction partners, to establish a reputation within the network-based system 
1 12 over time. Other potential trading partners may then reference such a reputation 
for the purposes of assessing credibility and trustworthiness. The feedback for each 

1 5 seller is placed in respective feedback tables 236. 

In order to allow listings and/or products, available via the network-based 
system 1 12, to be published in a visually informing and attractive manner, the 
marketplace applications 410 may include one or more imaging applications 430. 
Sellers may upload images for inclusion within offer listings using J2ME, MMS, 

20 and WAP or other microbrowsers. An imaging application 430 also operates to 
incorporate images within viewed offered listings. The imaging application 430 
may also operate to publish the identifier 166 associated with the listing 164 on the 
display 162. The imaging applications 430 may also support one or more 
promotional features, such as image galleries that are presented to potential buyers. 

25 For example, sellers may pay an additional fee to have an image included within a 
gallery of images for promoted offers. 

The marketplace applications 410 may include one or more offer creation 
applications 432. The offer creation applications 432 allow sellers conveniently to 
author products pertaining to goods or services that they wish to transact via the 

30 system 1 12. Offer management applications 434 allow sellers to manage offers, 
such as goods, services, or donation opportunities. Specifically, where a particular 
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seller has authored and/or published a large number of products, the management of 
such products may present a challenge. The offer management applications 434 
provide a number of features (e.g., auto-reproduct, inventory level monitors, etc.) to 
assist the seller in managing such products. One or more post-offer management 

5 applications 436 also assist sellers with a number of activities that typically occur 
post-offer. For example, upon completion of an auction facilitated by one or more 
auction applications 422, a seller may wish to leave feedback regarding a particular 
buyer. To this end, a post-offer management application 436 may provide an 
interface to one or more reputation applications 428, so as to allow the seller 

10 conveniently to provide feedback regarding multiple buyers to the reputation 
applications 428. 

The marketplace application(s) 410 may also further include one or more 
escrow application(s) 446 and the escrow account 450. In certain environments, 
the escrow application(s) 446 of the marketplace applications 410 may replace the 

15 funds release application(s) 146 of the payment applications 132 in the system of 
Figure 1 and in the interaction chart of Figure 4. In addition, the escrow account 
450 of the marketplace applications 410 may replace the holding account 150 of the 
payment applications 132 in some environments. The escrow account 450 may be a 
transaction-specific escrow account, and/or the escrow account 450 may be a seller- 

20 specific escrow account for each pending seller transaction. In either instance, the 
seller may associate collateral with the holding account directly or through another 
seller account associated with the payment application(s) 452. 

A risk model 447 of the escrow application(s) 446 may operate in a manner 
similar to the risk model 147 of the funds release application(s) 146, as previously 

25 described, to assess risks associated with each transaction. The risk model 447 may 
likewise, based on the information received from various sources (e.g., database 
tables 200 of Figure 3), determine the risk level of the payment transaction using a 
scoring algorithm. The risk model 447 may likewise consider factors such as the 
seller-specific criteria, the buyer-specific criteria, and/or the transaction-specific 

30 criteria, previously discussed herein. The risk model 447 may indicate, for example, 
that service should be denied to a participant (buyer or seller) due to high likelihood 
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of fraud, may recommend, for example, a service fee for processing the payment 
transaction, payment instruments to be used by either the buyer or the seller, 
approval by buyer before release of funds from the escrow account 450, and/or 
restrictions (e.g., time or amount held) on disbursing funds to the seller. 
5 The payment application (s) 452 may replace the payment application(s) 1 32 

of the network-based system 1 12 of Figure 1 in certain environments. The 
payment application(s) 452 may include the payment transfer module 142, the fraud 
prevention application(s) 144, and the dispute resolution application(s) 148, as 
previously described. 

1 0 In other embodiments, a seller and/or a buyer is able to dynamically choose 

between a variable payment option as described in the system of Figures 1 and 2, 
and an escrow option as described in the system of Figure 5.. The ability to choose 
may be based upon seller attributes, buyer attributes, or other criteria. The seller 
may choose to offer one or both options, e.g., in competitive environments, and the 

15 buyer may then choose or agree to the payment option used. 

Even though the context of this description is with regard to marketplace 
applications, it is to be understood by those of skill in the art that the described 
subject matter may also be applicable to other types of applications for various types 
of transactions. The transactions may include those between a single seller and a 

20 single buyer or may include those between a single seller and multiple buyers, and 
may include selling a catalog-type product, or even a more unique product. 



Computer System 

Figure 6 shows a diagrammatic representation of a machine in the example 
25 form of a computer system 500 within which a set of instructions, for causing the 
machine to perform any one or more of the methodologies discussed herein, may be 
executed. In alternative embodiments, the machine operates as a standalone device 
or may be connected (e.g., network) to other machines. In a network deployment, 
the machine may operate in the capacity of a server or a client user.machine in 
30 server-client user network environment, or as a peer machine in a peer-to-peer (or 
distributed) network environment. The machine may be a server computer, a client 
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user computer, a personal computer (PC), a tablet PC, a set-top box (STB), a 
Personal Digital Assistant (PDA), a cellular telephone, a mobile device, a palmtop 
computer, a laptop computer, a desktop computer, a personal digital assistant, a 
communications device, a wireless telephone, a land-line telephone, a control 
5 system, a camera, a scanner, a facsimile machine, a printer, a television, television 
cable a pager, a personal trusted device, a web appliance, a network router, switch 
or bridge, or any machine capable of executing a set of instructions (sequential or 
otherwise) that specify actions to be taken by that machine. 

Further, while a single machine is illustrated, the term "machine" shall also 
10 be taken to include any collection of machines that individually or jointly execute a 
set (or multiple sets) of instructions to perform any one or more of the 
methodologies discussed herein. 

The example computer system 500 includes a processor 502 (e.g., a central 
processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 
15 504 and a static memory 506, which communicate with each other via a bus 508. 
The computer system 500 may further include a video display unit 510 (e.g., a 
liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 
500 also includes an input device 512 (e.g., a keyboard), a cursor control device 514 
(e.g., a mouse), a disk drive unit 516, a signal generation device 518 (e.g., a 
20 speaker) and a network interface device 520. 

The disk drive unit 516 includes a machine-readable medium 522 on which 
is stored one or more sets of instructions (e.g., software 524) embodying any one or 
more of the methodologies or functions described herein. The instructions 524 may 
also reside, completely or at least partially, within the main memory 504, the static 
25 memory 506, and/or within the processor 502 during execution thereof by the 
computer system 500. The main memory 504 and the processor 502 also may 
constitute machine-readable media. 

The instructions 524 may further be transmitted or received over a network 
526 via the network interface device 520. 
30 Applications that may include the apparatus and systems of various 

embodiments broadly include a variety of electronic and computer systems. Some 
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embodiments implement functions in two or more specific interconnected hardware 
modules or devices with related control and data signals communicated between and 
through the modules, or as portions of an application-specific integrated circuit. 
Thus, the example system is applicable to software, firmware, and hardware 

5 implementations. 

While the machine-readable medium 522 is shown in an example 
embodiment to be a single medium, the term "machine-readable medium" should be 
taken to include a single medium or multiple media (e.g., a centralized or distributed 
database, and/or associated caches and servers) that store the one or more sets of 
10 instructions. The term "machine-readable medium" shall also be taken to include 
any medium that is capable of storing, encoding or carrying a set of instructions for 
execution by the machine and that cause the machine to perform any one or more of 
the methodologies of the present invention. The term "machine-readable medium" 
shall accordingly be taken to include, but not be limited to, solid-state memories, 
1 5 optical and magnetic media, and carrier wave signals. 

The illustrations of embodiments described herein are intended to provide a 
general understanding of the structure of various embodiments, and they are not 
intended to serve as a complete description of all the elements and features of 
apparatus and systems that might make use of the structures described herein. Many 
20 other embodiments will be apparent to those of skill in the art upon reviewing the 
above description. Other embodiments may be utilized and derived therefrom, such 
that structural and logical substitutions and changes may be made without departing 
from the scope of this disclosure. Figures 1 to 6 are merely representational and 
may not be drawn to scale. Certain proportions thereof may be exaggerated, while 
25 others may be minimized. Accordingly, the specification and drawings are to be 
regarded in an illustrative rather than a restrictive sense. 

The following description includes terms, such as "up", "down", "upper", 
"lower", "first", "second", etc. that are used for descriptive purposes only and are 
not to be construed as limiting. The elements, materials, geometries, dimensions, 
30 and sequence of operations may all be varied to suit particular applications. Parts of 
some embodiments may be included in, or substituted for, those of other 
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embodiments. While the foregoing examples of dimensions and ranges are 
considered typical, the various embodiments are not limited to such dimensions or 
ranges. 

The Abstract is provided to comply with 37 C.F.R. § 1.74(b) to allow the 

5 reader to quickly ascertain the nature and gist of the technical disclosure. The 
Abstract is submitted with the understanding that it will not be used to interpret or 
limit the scope or meaning of the claims. 

In the foregoing Detailed Description, various features are grouped together 
in a single embodiment for the purpose of streamlining the disclosure. This method 

10 of disclosure is not to be interpreted as reflecting an intention that the claimed 

embodiments have more features than are expressly recited in each claim. Thus the 
following claims are hereby incorporated into the Detailed Description, with each 
claim standing on its own as a separate embodiment. 

Thus, embodiments describe a method and a system to automatically transfer 

1 5 payment to a third party, for example, as part of a request from a network-based 
device. Although embodiments of the present invention have been described with 
reference to specific example embodiments, it will be evident that various 
modifications and changes may be made to these embodiments without departing 
from the broader spirit and scope of embodiments as expressed in the subjoined 

20 claims. 
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CLAIMS 

1 . A computer-system to transfer payment to a seller of a commerce 
transaction, the computer-system comprising: 

5 a funds release module to: 

generate a risk model based on seller-specific criteria; and 

automatically release funds from a holding account to the seller based on the 

risk model, wherein an amount of the funds that are released from the holding 

account varies according to the seller-specific criteria. 

10 

2. The computer-system of claim 1 wherein timing for release of the funds 
from the holding account varies according to the seller-specific criteria. 

3 . The computer-system of claim 1 wherein the release of the funds is further 
1 5 based on buyer-specific criteria and transaction-specific criteria. 

4. The computer-system of claim 1 wherein the holding account includes an 
escrow account. 

20 5. The computer-system of claim 1 wherein the release of the funds is 
independent of buyer approval. 

6. The computer-system of claim 1 wherein the seller-specific criteria includes 
a security proxy selected from a group including: collateral associated with the 
25 holding account from the seller, a social security number of the seller, a financial 
services provider account number of the seller, a feedback number associated with a 
commerce system, a complaint rate, a seller transaction history, and a tenure time 
associated with the commerce system. 
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7 . The computer-system of claim 1 wherein the release of the funds to the 
seller is completed in a plurality of stages over a period of time, wherein the 
plurality of stages and the period of time is determined by the seller-specific criteria. 

8 . A computer-implemented method to transfer payment to a seller of a 
commerce transaction, the computer-implemented method comprising: 

generating a risk model based on seller-specific criteria; and 
automatically releasing funds from a holding account to the seller based on 

the risk model, wherein an amount of the funds that are released from the holding 

account varies according to the seller-specific criteria. 

9. The computer-implemented method of claim 8 wherein timing for release of 
the funds from the holding account varies according to the seller-specific criteria, 

1 0. The computer-implemented method of claim 8 wherein releasing of the 
funds is further based on buyer-specific criteria and transaction-specific criteria. 

1 1 . The computer-implemented method of claim 8 wherein the holding account 
includes an escrow account. 

1 2 . The computer-implemented method of claim 8 wherein releasing of the 
funds is independent of buyer approval. 

1 3 . The computer-implemented method of claim 8 wherein the seller-specific 
criteria includes a security proxy selected from a group including: collateral 
associated with the holding account from the seller, a social security number of the 
seller, a financial services provider account number of the seller, a feedback number 
associated with a commerce system, a complaint rate, a seller transaction history, 
and a tenure time associated with the commerce system. 
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14. The method of claim 8 wherein releasing of the funds to the seller is 
completed in a plurality of stages over a period of time, wherein the plurality of 
stages and the period of time is determined by the seller-specific criteria. 

5 15. A machine-readable medium storing a sequence of instructions that, when 
executed by a computer, cause the computer to perform the method of claim 8. 

16. A computer system to transfer payment to a seller of a commerce 
transaction, the system comprising: 
10 means for generating a risk model based on seller-specific criteria; and 

means for automatically releasing funds from a holding account to a seller 
based on the risk model, wherein an amount of the funds that are released from the 
holding account varies according to the seller-specific criteria. 

15 17. The computer system of claim 16 wherein the means for generating the risk 
model and the means for releasing funds including a funds release module. 
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